In any enterprise, data regarding aspects thereof is accumulated over time. This data can be used to report the status of the enterprise. For example, with regard to a sales enterprise, sales data can be accumulated pertaining to each sale of a product, including the salesman, the customer, the region of the salesman, the region of the customer, the amount of the sale, the quantity of the product sold, the date of the sale, the date of the delivery of the sold product, and so on. Based on such sales data, then, it may be that a report is generated that details sales by year, by month, by customer by year, by product by quarter, by salesman by delivery date, by region by week, etc.
The data that populates a report will typically be accumulated in a data source, such as a database. A data source, as the term is used here, is a storehouse for digitally recorded data. In order to filter the data in a data source into properly organized columns and rows for a report, a report designer may specify, in a report design, the particular data that is desired from a data source. For example, a report designer might specify that he wants a “salesman name” in the first column of a report.
The report designer may then write a program that recognizes a field indicated for the first column of a report design (salesman name), queries a data source for all salesman names, and places them one after the other in the first column of a report. Instead of writing his own program to carry out this task, the report designer may use commercial software that provides this function. Such software may allow a report designer to simply specify, in a report design, a type of data he wants in the first report column. The commercial software will then automatically analyze the report design, query a database, and place the desired data in the first column of a report. This operation is also available in commercial products for any number of columns and/or rows of a report.
FIG. 1a, FIG. 1b, and FIG. 1c give an example of various views of a generated report. As shown in these figures, some of the items in a report may be initially hidden from view. These hidden items may be made visible by a consumer of the report, typically by selecting an area in a report item such as control image 130. FIG. 1a, FIG. 1b, and FIG. 1c will be discussed in greater detail below, after a more thorough discussion of report processing software in connection with FIG. 2, FIG. 3, and FIG. 4.
An exemplary report design is illustrated in FIG. 2. The exemplary report design provides a salesman column 201, a 1990 sales column 202, and a total sales column 205. This report design may be submitted to supporting software that can pull the corresponding data from a data source to populate the actual report. An example of such an actual report is provided in FIG. 3. FIG. 3 shows a populated salesman column 301, a populated 1990 sales data column 302, and a populated total sales column 205.
Exemplary report processing software for populating a report design with appropriate data is depicted in FIG. 4. The report processing software 410 may comprise a plurality of data extensions for properly interpreting the data stored in any of a plurality of data sources 420 and 421. The report processing software may also comprise a number of rendering extensions 412 to properly output reports in an appropriate file format, e.g. Hyper-Text Markup Language (HTML) 430, Extensible Markup Language (XML) 431, or some other file format 432. A report design 400, also referred to herein as a report definition, is used by the report processing software to identify the data to be gathered from data sources 420, 421 and compile the data into a properly structured report, outputting the report in any file format 430, 431, 432. This process is described in greater detail in U.S. patent application Ser. No. 10/400,734, which is hereby incorporated by reference in its entirety.
Reporting is moving away from traditional presentation on paper to presentation on the display surface of Graphic User Interfaces (GUIs). This may be driven by an increase in the amount of data available for reports, which makes static paper presentation of reports less appealing. It may also be driven by improvement in the quality and availability of computing technology for displaying reports. In connection with this shift in report display, reporting is increasingly making use of dynamic, rather than static views. Dynamic views allow a user to interact with a report to control the data that is displayed, while static views do not allow users to control the display properties of a report. The traditional means for controlling the visual state of report items is illustrated in FIG. 1a, FIG. 1b, and FIG. 1c. FIG. 1a shows a view of a report in a collapsed view, FIG. 1b shows a view of the same report in an expanded view, and FIG. 1c shows the same report in a further expanded view.
The features FIG. 1a, FIG. 1b, and FIG. 1c are familiar to those of skill in the art as well as to many consumers who have used reports incorporating such visual state control technology. In general, a report may be presented in an initial visual state as shown in FIG. 1a. In this initial visual state, a number of items 120-124 are visible, i.e. their visual state is “on.” For example, control item 120 is visible in FIG. 1a. 
In exemplary FIG. 1a, control item 120 is a column heading identified as “customer.” A user of such a report would imply that when additional items are displayed directly underneath control item 120, those additional items will contain customer data. There are various other visible items 121-124 in FIG. 1a, which provide additional information about the data contained in the report. Note that these additional items 121-124 are not “control” items, in that the display of additional data cannot be controlled from items 121-124. Instead, items 121 and 122 suggest that a year data column and a sales data column, respectively, will be presented alongside the customer data column when the report is expanded. Items 123 and 124 provide grand total data, which may be convenient for a quick review and summary of the contents of the report.
The status of control item 120 as an item from which the visual state of additional items can be controlled is traditionally represented by the small control image 130 within the control item 120. Such an image 130 may also be placed alongside a control item 120. This control image 130 indicates to users that performing an action on the control item 120, such as clicking on the control item 120 or clicking on the control image 130, will change the visual state of items directly beneath the control item 120. The image 130 is traditionally either a plus (+) or a minus (−) sign. The plus sign 130 indicates that the items directly beneath a control item 120 are not visible, while the minus sign 132 from FIG. 1b indicates that items directly beneath a control item 107 are visible. In this manner, the control image 130, 132, suggests an action to a report user: the plus suggests adding items to a report display, while the minus suggests subtracting items from a report display.
FIG. 1b illustrates the exemplary report in FIG. 1a after the control item 120 has been used to toggle the visual state of the items directly beneath the control item 120. As shown, a list of subitems 108 is now visible in the report. This list 108 is directly beneath the control item 107. The list 108 traditionally first appears in a collapsed view as in FIG. 1b, instead of fully expanded as in FIG. 1c. In the example provided by FIG. 1a, FIG. 1b, and FIG. 1c, each of the customer headings 101a and 101b are themselves control items which can be further used to control the visual state of lists of subitems 106 and 109 as shown in FIG. 1c. 
FIG. 1c presents a fully expanded view of the exemplary report. Each of the control images, e.g. 131, is displayed as minus symbol, indicating that the control items 105, 165, 166 can be used to remove items from the report display by toggling their visual state to “off.” The control items 105, 165, 166 in FIG. 1c cannot, however, be used for any further control of the visual state of the items. Moreover, the set of items controlled by the control items 105, 165, 166 is limited to the list of subitems, e.g. 109, 106 directly beneath each control item 105, 165, 166.
FIG. 1a, FIG. 1b, and FIG. 1c demonstrate the current state of the art in commercial report design software for flexibly controlling the visual state of items in a report. One drawback of such systems is the inability to allow further control of the visual state of items beyond toggling all items between a visual state of “on” and a visual state of “off.” Another drawback is the inability to control the visual state of any items beyond those directly below a control item.
Further, if such drawbacks are to be resolved, the current report design technology does not offer an easily understandable technique for defining the relationships between control items and the items whose visual state is toggled from the control items—the toggled items. Those who use report design software to design reports are not necessarily advanced computer programmers. If the flexibility of report design software is to be increased, it should be accompanied by easily understandable techniques for harnessing increased design power.
In light of the drawbacks in the commercial software industry for supporting report design, there is a need to provide easily understandable techniques for designing reports that result in more freedom to control the visual state of report items, and to provide software mechanisms to support such techniques for designing reports.